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for managing clinical trial I 

data includes dynamically J 

generating, at a server, 
a data entry form to be 
displayed "at a client. 
The data entry form is 
generated dynamically in 
a SGML-derived language. 
Control elements within 
the form comprise images 
which are used to construct 
the control elements 
and larger controls. The 
form is generated from a 
protocol database and a 
context received from the 

client, is populated from - y — 

the data database, and is / / 

published to the client. |Q5 107 

Templates based on the 
protocol database comprise 
several frames including 
intermediate frames for 
displaying frame borders 
which are non-horizontal 

and non-vertical. If the trial protocol changes during a trial, the generated form is based on the protocol version active at the time aata 
was entered into the form. Irfadvertent use of the application is discouraged requiring an authentication procedure and displaying a picture 
of the authenticated user. Furthermore, help is provided by creating a link between the text of each question and information about the 
question. The source of help may -be any or all of a protocol document, an investigative brochure, and a study guide. In addition, a user, 
upon logging in, is presented withja^shboard screen which provides information or links to information such as trial-related news, alerts, 
statistical information, progress reports and a list of work to be completed. 
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CL'INI CAL : TRIAL DATA MANAGEMENT SYSTEM AND METHOD 

COPYRIGHT NOTICE. 

• A portion of the disclosure of this patent document 
contains material which is subject to copyright 
5 protection. The copyright owner has no' objection to the 
facsimile reproduction by anyone of the patent document . 
or- the patent disclosure, as it appears in the Patent 
and Trademark Office patent file or records, but 
' otherwise reserves all copyright .rights whatsoever. 

10 BACKGROUND OF THE INVENTION 

Once a pharmaceutical, medical device manufacture 
or bio- technology company has developed a treatment, 
■' device or. drug therapy, approval from a regulatory 

authority, such as the FDA in the US , must be obtained 
15 before it can be made available through prescription. 

The submission to the regulatory authority consists of a 
large volume of information, including clinical 
information which focuses on the safety and efficacy of 
the therapy. Much of that information is collected by 
.20 conducting clinical trials. 

A pharmaceutical, medical device manufacture or 
bio -technology company sponsors a series of clinical 
trials. Either an internal clinical group manages these 
trials or they are out-sourced to a clinical research 
25 organization (CRO) . The clinical group or CRO contracts 
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• with investigation sites that in turn recruit patients 
for the study and collect the clinical data. 

The clinical trials are performed in a series. of 
phases, known as Phase I, Phase II,. Phase III, and Phase 
5 IV. Each phase varies- in duration, the number of - 

patients involved and' purpose. ■ Failure at any stage of 
Phases I, II or III "of the clinical trial process 
effectively ends the therapy's chances for final 
approval. 

10 Before entering Phase I, the sponsor needs to 

obtain regulatory approval . Phase I trials typically 
last six months and. involve tens. of volunteer subjects 
usually. all of whom are located at a single 
investigative site. Phase I trials test the safety of 

15 . the therapy. Once Phase I trials are complete . and the 
therapy has been. shown to be safe, the sponsor requests 
permission from the regulatory authority to proceed with 
further clinical' tests. 

Phase II trials typically last six to twelve 

20 months, involve tens to hundreds of patients and are 
conducted to test the effectiveness of the. treatment , 
device or drug.. .A sponsor may conduct many Phase II 
trials, attempting to find as many uses of the therapy ' 
as possible. If the therapy appears to be effective, 

25 the sponsor requests permission from the regulatory ./ 
authority to proceed. with large scale trials. 

- For each likely use of the therapy, the sponsor • 
conducts at least two Phase III trials. Phase III 
trials typically last 24 to 3 6 months and involve " 

30 thousands of patients. Phase III trials are blinded 
trials, that is, a portion of the patients receive the 
.therapy and the remaining patients receive a placebo or 
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active control, and the identities of patients- taking 
the trial therapy are. not known to anyone until the 
trial is complete. Phase III trials are conducted to 
test the safety and effectiveness of a therapy in a 
5 large population . The Phase III trial is the first 

• • opportunity to' observe infrequent adverse effects in the 

general population; each and every one is carefully 
recorded. Since the effectiveness of the therapy is 

• , . • tested in a blinded environment, .the results - are not 
10 known until . after the. study is complete. 

Phase IV trials occur after approval and are 
generally held to obtain approval to change a 
characteristic such as the delivery system, e.g., from 
liquid to tablets, or to change the status, e.g., from, a 
15 .prescription drug to an over-the-counter drug. Failure 
at any stage of a' Phase IV trial effectively ends the 
therapy's, chances of "obtaining approval for such a 
change . 

..Every clinical trial has a protocol which specifies 
20 the exact timing and nature of the' measurements and 
interventions to be performed on. each patient . The 
protocol ' s time-line lists a series of .events, or 
visits, where the data, are collected from the study 
patient. The time-line of a typical - study starts with 
25 the screening and enrollment of a patient and typically 
ends with the last patient visit .. v . ■; 

Fig. 1 illustrates the preparation and processing 
of paperwork in a typical clinical trial. There are a 
number of points in the process where the data are 
30 audited and reviewed. A patient 401 visits the 

investigative site 413. For each visit, the protocol 
instructs the investigator to collect certain 
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information. 403 about the patient 401. After the 
information 403 is collected, it is recorded on a Case 
Record Form (CRF) 405. Periodically, a Clinical 
Research Associate (CRA) 41-7 visit's the . investigative 
5 site 413 and compares the data in the original medical ■ 
record 403 with the information on the CRF 405. This 
process 406 is known as source document validation; or . 
SDV. ' - " 

• Once the CRF has been source document verified, .CRF 

10 405 is delivered to the organization 407 running the 

trial (either a CRO or an internal clinical group at the 
■sponsor) as indicated by arrow 403. When the CRF 405 " 
arrives, at the sponsor /CRO 4 07, its data is entered into 
a clinical database 409 twice to ensure that no errors 

15 are introduced, as indicated by arrows 410A and 410B. 

A medical monitor 415- and clinical data manager . 
(CDM) 419. at the sponsor/ CRO 4 07 examine the CRF 4 05 to 
look for inconsistencies. If any of the data are 
- incomplete or appear incorrect, the . CRF is sent back to 

20 the investigative site. 413 with a query . 411 . for 

correction, a process known as cleaning. If someone at - 
the investigative site 413 makes a change as"a result of 
a query 411, the data is again source document verified 
by the CRA 417, and is sent back to the sponsor/CRO 4 07 

25 for data entry, as identified by arrow 412. When all of 
the data cleaning is complete, the clinical database 409 
is locked and data analysis begins. 

As. can be seen, a' large volume of data is collected 
during each clinical trial, and. the collection and 

30 management ' of clinical data is a large problem that 
requires many people performing a number of different 
and, unique roles. These roles fall into three groups:' 
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the investigative site roles, the clinical data review 
roles,-' and other central sponsor roles. 

SUMMARY OF THE INVENTION 

Implementing such a system or method on the Web has. 
5 the obvious advantage of ease -many people are now 
familiar with Web technology and even those with 
computerphobia are becoming comfortable accessing the 
Web. In addition, because browsers are so inexpensive, . 
while the personal computers on which they run can 
10 typically be had for under $1,000, there are no major 
expenses involved, for other than the development of the 
clinical trial database. No special, software needs to 
be distributed. .. . 
On the. other hand, one disadvantage is that access 
15. over the Web can.be considerably slower than a direct, 
connection to a host server. Another is that certain-. _ 
things that can be . done easily, in a closed environment 
with custom software, such as curved boundaries between 
frames, are " not so readily done on the Web. .The present 
20 invention is aimed at overcoming these and other 
. disadvantages. . 

Therefore, a method of implementing a graphical 
■ user interface (GUI') control element within a client 
browser, comprising creating several bitmaps which can . 
25 be constructed to present the GUI control element in a 
variety of different states. A Standard Generalized 
Markup Language (SGML) -derived language such as HTML or 
XML is used to specify placement of the bitmaps within a 
document. Upon receipt of the document, a browser 
.30 displays a desired GUI control. 
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Preferably,. placement of the bitmaps is specified • 
' by -placing indicators such" as -URLs corresponding to the 
bit maps in certain locations , preferably table entries, 
within the document, such that the browser will 
5 correctly- display, the control element. Preferably, 
these bit maps are- used by many similar GUI controls. 

Furthermore, a bitmap may be .partitioned' into 
•multiple sections, where each section is associated with 
a. different indicator.. . 
10 In' particular, in a preferred embodiment , one type . 

' of control element is a button control which comprises • 
left," right, top and. bottom pieces. ' A "label is placed ■ 
between the top and bottom pieces. 

Another type of control element is a file tab, or . 
15 tab, control, comprising left, right, top and bottom, 
pieces. A label is placed between , the top and bottom 
pieces.- Multiple tab controls can be grouped together / 
sharing bitmaps which have 'a left or - right overlapping 
piece. Different bitmaps also provide different styles 
20 such as color to portray a selected. or non- selected tab. 
Yet another type of control is a linear control 
which comprises button control elements spaced at. 
intervals' along a line. Each button control element has 
• a corresponding bit map or combination of bit maps. A - 
25 pointer indicating a current value along the line also 
. has an associated bitmap. • •- 

In the preferred' embodiment , the server is 
stateless with respect . to the GUI controls. That-is, 
when a request is received,, the server has" no knowledge - 
30 of the states of the controls other than . what is sent in 
the request . 
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The present invention also provides a method of 
entering clinical trial data from, a client, where the . 
data is maintained on a server. A data entry -form to be 
displayed at the client', is generated at the server 

5 dynamically in a SGML-derived language/ from a library 
of code fragments. The form, is generated according to 
the user, the patient, the protocol version within a 
clinical trial and data previously, entered'. . 

In a preferred embodiment, a protocol, or clinical, 

10 database is created which is specific to an application. 
A data database is created which is specific to a 
subject processed by the application. Then the form is. 
generated based on the protocol database, preferably 
based oh a clinical protocol, and a context received 

15. from the client '. Preferably this is done by generating 
a template based on the protocol database and a context 
received from the client. The form or template is 
populated with application data fronv the data database, 
and published to the ' requesting client browser. 
'•■ 20 Preferably, the template comprises several frames 

including control frames with one or more control 
elements. An intermediate frame presents a visual 
attribute shared by .the control frames. The appearance 
of the intermediate frame depends on the visual • 

25 appearance of the control frames. ;. 

In addition, in a preferred embodiment, protocols' 
can be changed during the trial . The generation of the 
template is then further based . on the' protocol version 
which was active at time of entering data to be 

30 displayed. Thus the form to be displayed is itself 

based on the protocol version which was active at time 
data _was entered. 
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Furthermore, in a preferred embodiment, rules are 
associated with the displayed form, and are based on the 
protocol version which was active at the time of 
entering data to be displayed- in the form. 
5 Yet another* aspect of a preferred embodiment of- the 

present invention is the discouragement of inadvertent 
use of a computer application, by requiring a log-on 
procedure for each user, and displaying a picture of the 
currently logged- on user. 
10 Still another aspect of a preferred embodiment of 

the present invention is the provision of context- 
.-.sensitive help. .Preferably, a displayed form has at 
least one question to which a user must respond to 
provide clinical data. ■ Links are created between the 
15 • text of each question and detailed information related 
to the question. If the user clicks on text of the 
question; detailed information corresponding to the 
question is retrieved f rom ^the server is displayed. 

Preferably, the detailed information is r derived 
20 from any .or all of three source documents defining the 
clinical trial: a protocol document, an investigative 
brochure, and a study guide. Pref erably , . the user can 
walk through each of the documents. 

-Another aspect of the present invention is the • 
25 dashboard screen which. provides information regarding 
the trial, customized for the user and presented to the 
user upon logging in to the system. Such information- 
- preferably includes but is not limited to trial -related 
news, alerts, statistical information, progress reports 
.30 . and a list of work to be completed 

BRIEF., "DESCRIPTION OF THE DRAWINGS 
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The foregoing and other objects, features- and 
advantages of the invention will be apparent from the 
•following more, particular description of preferred 
embodiments of the invention, as illustrated in the 
5 accompanying drawings in which like reference characters 
refer to the same parts throughout the different views. 
The drawings are not necessarily to scale', emphasis 
instead being placed upon illustrating the principles of 
the invention. 

10 Fig. 1 is a block- diagram illustrating current 

trial data collection practice. - 
. . Fig. 2 is a block diagram illustrating" the present 

invention's implementation of a clinical trial data 
."■ management system . operating over the Internet and the _ 
. . 15 World Wide Web. . .. • 

.Fig. 3 is a block diagram illustrating the general 
flow of -operation and data in the present invention. 

Fig. 4A is a diagram illustrating a Web page 
comprising a typical clinical form created by. the 
20 present invention. 

Figs. 4B and 4C, are illustrations depicting the . 
hierarchical structure of a form such as that of Fig. 4A 
within the present invention. ^ 

Fig. 4D is a . schematic . diagram illustrating the 
25 . dynamic .construction of a form template and the. 
resulting document within the present invention. 

.Fig. 5 is a diagram illustrating how the form of 
..• Fig. 4A might appear for a different user. 

Fig. 6 is a diagram of a login screen. 
3.0 Fig. 7 is a diagram illustrating the . dashboard 

screen of the present invention. • 
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Fig. 8 is a diagram illustrating intermediate, 
frames as used by the present invention. - 

. Fig. 9 is a diagram illustrating how a button 
control of the present invention comprises bit maps laid 
"5 out in a table. . 

Fig.' 10A-10C are diagrams illustrating • how the tab 
control; of the present invention comprises bit maps laid 
■ out in a table . 

Fig. 11A-11D are diagrams illustrating a linear 
10 control of the present invention.. 

Fig. 12A is a flowchart illustrating " the present 
invention's use of study protocol version control . 

Figs. 12B and 12 C are . illustrations showing the 
same form under two different protocol versions. 
15 . Figs. 13A-13F are diagrams illustrating the use of 

context sensitive help as employed by the present . 
invention . . 

. DETAILED DESCRIPTION OF THE INVENTION 

The present invention provides a means of \ 
20 expediting the process by collecting and managing trial, 
data including communications between sites over the 
-. Internet, using a World Wide Web (Web) server in 

combination with Web browsers which run on most personal 
computers. Such a system requires little to no ■ 
25 investment. Communication between parties is near-;. 

instantaneous ,'. and can be saved as part of the record.. 
Checks" can be performed automatically and 
instantaneously. This allows faster processing of the ' 
data, and faster . .availability of the data: A 
30 significant amount of time is cut out the trial time, 
allowing the sponsor to get its product to market 
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sooner, .saving millions of dollars, and potentially 
aiding thousands or millions .of potential recipients of 
the ' treatment much sooner than the treatment might 
otherwise be available. 
5 The Internet is a world-wide computer network which 

actually comprises thousands, of smaller networks 
connected to the. Internet backbone, thus linking 
millions of computer users around the world. The Web is 
a. technology which allows .a .user to format a document 

10 according to some standard. The document is made 

accessible to a Web server which transmits the document, 
to another user' upon request. When the document is 
. . received .by the requestor, running a Web browser, the 
browser knows how to construct and display, or render, 

15 the document. 

Requests are made to a Web server using a Uniform 
Resource- Locator (URL) which identifies the Web server, 
and the specific document. These documents are often 
called Web "pages" . ■ ■ 

20 One common format for transmitting these documents 

is known as Hypertext Markup Language (HTML). HTML 
allows the creator of a document to specify the 
-appearance and placement of a variety of things such as 
font size, style, headers and so, including placement of 

25 data or pictures within tables. 

If .a Web page is to. contain pictures, these 
pictures or images are often specified within the 
document by their respective source locations, where 
• they are stored as image files using formats such as 

30 u gif" or "jpeg" , for example .; These image files can be 
quite large and can consume an annoyingly large amount 
of time as a requesting party waits for the image files 
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to download. Of course, this is compounded when there 
are several image files to be downloaded. 

One feature of most Web browsers is the ability to 
cache information locally. Thus image files can be 
.5 stored in the browser's cache, so that if the user 

requests the same page at a later time, the browser uses ' 
the locally cached image files rather than downloading 
the files again. While this saves much of the time that 
would otherwise be wasted re -downloading the images, it 
10 does come with a cost: image files can be large and 
caching- many of them for hundreds or thousands of Web 
pages can consume a significant portion of local memory . 
Or disk space . 

Fig. 2 illustrates the present invention operating 

15 over the Internet. The Clinical Research Organization 
(CRO) or the sponsor's own internal clinical group 
responsible for maintaining trial data maintains an 
application server 103 which stores data about the 
protocol, the forms to be used, the roles of various 

20 individuals involved, etc., in a meta database 105. 
Actual clinical data collected during a trial is 
maintained in a trial database 107. Of course, while 
there are logically two databases, the actual data can 
be maintained in just one or many databases. 

25 The application server 103 receives requests via a 

network 109, such as the Internet, from users 111. at the 
investigative sites 112, sponsor sites 113, and CRO 
sites 114, and responds to the requests, presenting a .' ' 

consistent and secure interface through a Web server 

30 101. The Web server 101 transmits information to the 
requesting site as a document formatted according to an 
SGML*derived language, such as XML, or preferably, 



RNKDOTMfy <WO oc*fi3473A? I >• 



WO 99/63473 



PCT/US99/12406 



-13- 

hypertext markup language. (HTML) document. The document 
can also include small scripts in a language such as. 
Javascript for. implementing' certain rules at the user's 
site. Investigative sites 112 include, but are not 
5- limited to, hospitals, clinics and independent doctors' 
offices. 

During a clinical trial , various individuals have 
certain responsibilities which, are accompanied by 
privileged access to certain documents. In the present 
10 invention, these privileges are rigidly defined . Roles 
. are defined as a collection of privileges such that 
assigning a particular individual to a defined role 
. bestows upon that individual the collection of 
corresponding privileges. 
.15 For example, in the present invention, there are 

two primary roles' at the investigator site. The 
Clinical- Investigator and the Clinical Research 
- - Coordinator (CRC) gather the data for. the trial . 

according the protocol,, and record the data on CRFs 
20 which are sent to the sponsor for review and acceptance . 

The Clinical Investigator (CI) is responsible for 
treating his patients and executing the study protocol. 
He has the ultimate responsibility for all activities at 
his . site.. 

25'. The CRC is responsible for collecting all of the 

information about the patients in the study who are 
. being treated at the CRC's site, and for returning the 

information to the clinical group. . In the US this 
• individual is typically a nurse, while in Europe the 
30 role of the CRC is typically performed directly by the 
Clinical Investigator. 
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The people fulfilling these roles at the 
investigation site must be able to see information about 
all of their patients who have been screened or accepted 
■ into the study. This information includes a patient '.s 
5 visit, history, the contents of the CRF associated with 
the patient, and the patient's lab results to name a 
few . 

As clinical reviewers at the CRO or sponsor examine 
the answers to the. CRF questions, they may have 

10 questions or comments which require responses from the 
■ ' investigation site. These questions and comments are 
referred to as queries. The CI or CRC must be able to 
respond to a query, usually by attaching a comment to a 
question or CRF, by adding new or additional information 

15 to a CRF, or by changing information previously entered 
on the CRF." This is a key component of data cleaning. 
Once the 'query is resolved, the response is returned to 
the individual reviewer who issued the query. 

■During the course of a trial , some - patients may .. 

20 experience adverse events.. These events are noted by 
recording .a text description of the event , as well as a 
medical code for that event .. These codes are found in a 
number of coding dictionaries such as COSTART . If the 
adverse event is serious, the sponsor is notified 

25 immediately. 

. Some patients in the trials may take other 
medications during the' trial . These medications, 
whether taken regularly as for allergy medication, or 
occasionally such as aspirin for a headache, are.' coded' 

30 and stored in the patient's record. 

From time to time, the CI or CRC at the ■ 
investigation site must review some of the information 
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about the study such as the .study' protocol , the study 
reference manual, a study newsletter, and a list of 
frequently asked questions*. In addition, they must 
'review ..information .about individual questions on the CRF 
5 such. as getting a list of .all previous responses . to a 
question and viewing the discrepancy criteria for a 
question . 

■ During, a trial, a CI or CRC may need to communicate 
with a representative of the sponsor.-' For example, - 

10 initially the CI/CRC needs to provide information about 
the. site to the sponsor (Form 1571, lab normals, CVs of . 
the investigator).- As the study progresses, the CRC may 
have, a question or may notice something that would 
interest the sponsor. Much of this communication is 

15 included in the study files. 

In addition to communication with the sponsor, the 
investigation site may want to communicate with another 
site. Perhaps. an investigation site. wants to ask 
someone at another site. a question. These 

20 communications are not part, of the study data. . 

In addition to written communication with the 
sponsor, frequently the site will call someone at the 
sponsor. The content of many of these conversions may. 
need to be noted in the study data..' 

25 The study protocol may require a CI/CRC to sign 

the CRF pages either before the CRA performs the source 
document verification, when the patient book is complete 
or both. The .signature task can be .made easier for the 
investigator site by telling them which CRFs are 

30 complete and need a signaturie, and when data on a signed 
CRF has changed and needs another signature. 
Additionally, the investigator sites need to know which" 
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CRFs they have examined and which ones they have not 
examined . : 

The management of drug inventory during a study is. 
critical. A complete accounting of all study medication 
5 is required by the regulatory agencies.. The ' 

investigator site needs to dispense study medication to 
their patients in the study and record this transaction. 
Additionally-, when the sponsor issues study medication 
. to the investigator site, this transaction and the 
10 receipt of the study medication by' the investigation 
site must also be recorded.' 

Occasionally, the investigator site will need to 
break the study blind for a particular patient (for 
. example, when a study patient becomes pregnant.) This 
15 is an important transaction and it must be noted in the 
. study data . 

-There are four clinical review roles to be 
. performed at the Clinical Research Organization (CRO) 
and/or sponsor. The Clinical Research Associate (CRA) , 
20 Clinical Data Manager, Medical Monitor, and Clinical 

; Project Manager review the data that is generated by the 
investigator sites for completeness and consistency. 

The' Clinical Research Associate reviews all of the 
data provided by the investigator sites, ensures that 
25 the. sites are following the protocol and that all of the 
information in the medical record is completely and 
accurately represented in the study data.. Typically, a 
CRA is responsible for monitoring a number of sites, and 
their audit role requires them to visit their sites. 
30 The CRA needs to know exactly what is happening at all 
. of their sites so that they can effectively monitor the 
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site's activities. The CRA sends summary reports to the 
project manager and others at the sponsor. 

The Clinical Data Manager (CDM). prepares and 
maintains the clinical study database. The CDM is 

5 involved in the design of the study database, validation 
checks, .and the design of the CRFs . . The CDM also 
•reviews. the data in the database ensuring that the data 
is complete and consistent. 

.The Medical Monitor is often the designer of the 

10 study protocol and may be responsible for making any of 
the necessary changes to or deviations from the protocol- 
once that study has begun. The Medical' Monitor also 
reviews the study data looking for data. anomalies and . 
irregularities with respect to patient safety. Like the 

15 CRA , the. Medical Monitor reviews the data in the CRFs 
and the communications with the sites. The Medical 
Monitor may respond to a query from a CRA. Finally, the 
-Medical Monitor is immediately notified whenever a 
serious adverse event is recorded. 

.20 The Clinical Project Manager oversees the entire ■ 

data collection, process . They directly , manage the 
activities of the CRAs and CDMs and at times they will 
• examine the study data in detail . Together with the 
Medical Monitor, the Clinical Project Manager reviews 

25 the progress of the study and reports status to the 
senior management at the sponsor. 

To monitor a site effectively, a data reviewer 
periodically reviews the data in the CRFs. If a value 
is missing, the validity of a value is questionable, or 

30 there is some other cause for concern,, the data reviewer 
issues a query by attaching a question or comment to .a 
question on the CRF. 
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. Before a clinical database can be locked, - members 
of the review team may be required to 'sign the patient 
CRF books. The signature task is simplified by. 
indicating which CRFs are complete ' and need. a signature, 
5 and which data on a signed CRF has changed and requires 
another signature. In addition, the "data reviewer needs 
to know which CRFs have already been examined and which 
have not been examined. 

Just as the site must on. occasion communicate with 
10 the sponsor, .the data reviewer must 1 communicate with a 
site. These communications may or "may not' be included 
in the study data. In addition, some messages are 
. critical and investigator site personnel must see these 
messages before continuing. 
15 Data reviewers need to communicate with each .other . 

A CRA may have a question for the medical monitor, or 
'.■ the medical, monitor may notice something that they would 
like the. CRA to investigate. \ Unlike, queries , these 
communications are not part of the study database. • 
20 - Occasionally, one or more of the data reviewers 

will want to lock some or all of the patient 1 s records 
so that interim statistical analysis' can' be performed. 
A preferred embodiment of the' present invention provides 
. a mechanism for locking the data at a patient level. 
25 • The Clinical Research Associate .(CRA)',- has specific 

additional functions, as well. The CRA can view an 
investigator site's data and issue" queries to the sites. 

.Periodically, the CRA visits a site, reviews all of 
■the data iri the original medical records (the source . 
30 documents) and compares this with the information in the 
CRFs. This is known as source document verification. 
The- "QRA monitors a CRF at the question level, meaning 
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that part. of a CRF could be ' considered reviewed, but the 
rest will still need monitoring at a later time. In a 
preferred embodiment of the present invention, the CRA 
is automatically notified when any CRF is ready for 
5. review . 

.The CRA often does not have, access. to the primary 
study database and must, work off-line. Therefore,, during 
verification the site cannot change the data being 
reviewed until after the review is complete. 

10 . The CRA must manage the documents that are provided 

by the site. These . include any regulatory documents and-, 
any additional documents that are generated by the site 
that must be included with the study data . The CRA must 
notify the site when one of these documents is about to 

15 expire . 

From time to time, the CRA issues a report about a 
. site. For example, these reports are issued when a- site 
has been qualified for the study, when a si te. initiates 
a trial, after the CRA has monitored some of the data at 
20 a site, and when a site finishes .its last study patient. 

The Clinical Data Manager (CDM) also has specific 
additional functions. During the course of a. trial, the 
CDM may need to change one or .more of the discrepancy 
checks in the system. 
25 Typically, codes are entered not by the study 

.coordinator (CRC) but rather by the CDM. * f a CRC 
enters an adverse event, or concomitant medication 
without coding the data, the CDM supplies the 
appropriate code in the database . In addition, the CDM 
30 carefully reviews all coding of adverse events' and . 
concomitant medications, making any changes that are 
necessary for consistency. 
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The Medical Monitor is notified whenever a serious 
. adverse event is recorded. This notification occurs as 
quickly as possible to ensure the safety of the affected 
patient and all other patients in the study. 
5 The sponsor will occasionally send information to. 

all members of the study'team and/or to all of the 
sites - 

In addition, it is occasionally necessary for the 
Medical Monitor to change some part of the study 
10 protocol or CRFs .. If the change affects patient safety, 
the protocol' change must be reviewed by an Institutional 
Review Board at each site before it can be implemented. 
This leads to the possibility that two or more versions 
of the protocol could be active at different sites " 
15" simultaneously.. 

On rare, occasions the Medical Monitor allows a site 
to violate the study protocol. When this occurs, there 
must be a documented record of- the deviation with the 
. Medical Monitor's approval. Additionally/ the Medical 
20 Monitor must note the justification for the deviation in 
the study data. 

Occasionally, the Medical Monitor will- need to 
break the study blind for a particular patient (for 
example, when a. study patient" becomes pregnant) . . This 
25 is an important transaction and it must be recorded in 
the study data. 

The Clinical Project Manager will sometimes act as 
an -individual contributor CRA or CDM. • 

There are two other roles in the system which do 
30 not fit into any of the other categories. They are the 
Pharmacist and the Database Manager. Many investigator 
sites- will have their own pharmacy on site, or they will 
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wprk with a local pharmacy. In- either case, the 
Pharmacist must have access to the clinical trial data 
application . 

The Database .Manager is responsible for the 
5 security and reliability of the clinical .study database. 
During the design of the trial, the Database Manager 
works with the CDM designing the implementation of the 
data model for the trial. At the end of the trial, the 
Database Manager is responsible for moving the data out 
10 of the study database and into a statistical analysis 
database. 

From time to time, a pharmacist must review, 
information about the study such as the study protocol, 
the study reference manual, a study newsletter , and a 
15 - list of frequently asked questions. During, the study, 
the pharmacist may need "to communicate with the sponsor 
personnel. As the study progresses, the pharmacist may. 
have a question or. may notice something that would be of 
interest to the sponsor. Some of these communications 
• 20 must be included in the study data.. 

The management of drug .. inventory during a study is 
critical.. A complete accounting . of all study medication 
is required by the regulatory agencies . The site" needs 
to dispense study medication to their patients in the 
25 . study and record this transaction. In addition, when 
■ the sponsor issues study medication to the site, this 
■ transaction must also be recorded. 

When the study is complete and the database is 
locked, the Database Manager must- move. the study data 
30 ' into a: statistical database. The database structures of 
.. the clinical database must .support this conversion. 
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• Fig. '3 illustrates the general 'flow of operation 
and data in the present invention. While any Standard 
Generalized Markup Language (SGML) -derived language such 
as XML can be used, the preferred' embodiment of the 
. 5 present • invention utilizes Hypertext Markup Language 

(HTML) ". Rectangular boxes and solid bold lines indicate 
- process flow, 'while dotted lines indicate data flow. 

First, at 201, a request, is received from a user, 
i.e., an investigative site, a sponsor site, a CRO site 
10 .or. a pharmacist. The request 213 is saved, for later 
processing by any or all of the authentication process 
203, the application layout process 205, or the form 
creation process 207. 

Upon receipt of a request from a client, the 
15 authentication process 2 03 is invoked. . A user database 
215 is maintained, and the authentication process 203 
checks user information contained in the request 213 
against the user database 215. Such information may 
contain user identification, password, session ' 
20. .information, valid time, frame, etc., or. other equivalent 
authentication means. 

In addition to authenticating the user, ' the 
authentication process 203 examines the/ user- request 213 
and- checks with the user database 215 that the user, is 
25 authorized to make such' a request. The ' authentication 
process 203 can then establish which ' user rights 217 the 
user is to be given regarding 'the response to the 
•particular request. 

Once the requesting user' has been authenticated, an 
30 application layout process 205 begins to construct the 
layout of the HTML response 221 to the client. This is 
a top- layer describing what pieces are to be positioned 
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. . within- the HTML document, and where . For example, this 
layer, determines what the various frames should look 
like and what controls should appear therein. To make 
these decisions, the application layout process 205 
5 relies on the original, user' request 213, the user rights 
217 as determined previously by the authentication 
process 203, and descriptors maintained in' a descriptor 
database 219 . 

Once the .layout has been generated, .the form 
10 creation process 207 uses .the user request 213 and 
descriptor database 219 to determine .what questions, 
controls and other information should go into the form 
. in the HTML document 221 previously .laid out by the 
application layout .process 205. 
.15 Next, the HTML document 221 is populated with 

clinical data by a data population routine, which 
retrieves the data from a trial database 223. The 
document '221- is now complete and ready for transmission 
back. to the client (block 211). 
20 Fig. 4A illustrates a typical Web page 250 created 

by the present. invention, as- constructed from the' HTML 
document 221 (from Fig. 3) when received and displayed 
. by a client browser. .Panels 251A-251C derive from the 
part of the HTML document 221 constructed by the 
25 . application layout' process. 205 {Fig. 3), and contain . 
various controls and other general information. 

For example, panel 251A contains a photograph 257 
■of the person whose user identifier and password were 
used to first gain access to the system, or login. As 
30 discussed below, . a preferred embodiment of the present 
invention displays this photograph 257 for the purpose 
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■ of discouraging inadvertent use of the system by another 
person . 

Other controls 261 are also provided in this panel 
251A which permit the user to navigate to and examine . 
5 various related documents and other information pages. 
Links 269 to recently accessed documents or data are 
also provided. 

Panel 251B holds two additional controls: a time 
line control 263,. and a file tab. control 265. These., are 

10 special types '.of controls which were necessitated by the 
present invention, yet are not easily implemented in a ." 
Web application. They are discussed below. Note 
however, that the time line control 263 is used to 
select a specific week (or. some other unit of time) 

15 within the study, and that the. file tab control 265 is 
used, to select a particular form.. Appearance of the 
form, of "course, is dependent on the user's role, the 
protocol version and the week selected, . as well as the 
actual form selected. 

20 Finally, panel 251C holds controls 2 67 . related to 

the form, here, a Submit button and a Cancel button. 

Once the panels 251A-251C are laid out by the 
application layout process 205, the selected form layout 
253 is specified by the. form creation process 207 (Fig. 

25 3). In Fig. 4A, the "Demographics" ..form is displayed. ■ 
. Figs."4B and 4C depict the hierarchical structure 
of an electronic CRF 253, also referred to simply as a 
form, of the present invention. The form 253 comprises 
one or more sections '551. Two sections 551 of the 

30 Demographics form 253 are visible: a Demographics 

section and a Smoking History section The remainder of 
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the form can .be brought into view .by scrolling the 
' scroll bar '553 . 

Each section comprises one or more ..items in which 
the user is typically asked to provide information about 
5. a'patient, or if the information has already. been . 
provided, the information is displayed. For example, 
the Demographics section 551 has six items '554 numbered 
from 1 to 6, as well as a seventh item 555 in which a 
calculation is automatically performed by the system. 
10 ■ Each item 554 in turn, may comprise one or more 

control groups 556. For example, item 2 ( u Date of 
Birth") comprises control group 556, which in turn 
.comprises three controls 557A-557C (generally 557 in 
Fig. 4C) . Note that a control group may itself comprise 
15 control groups. 

Each, control may have one or more elements. For 
example ,- control 557A allows a user to select the 
-patient's date- of birth month. The twelve months . are- 
available in a list which is made visible by clicking on 
20. the arrow. Each month is an element 558 of the control 
• • 557A. . . .. 

The significance of this hierarchy is that each of 
• these hierarchical levels is treated as an object., with 
its. own HTML fragments. As illustrated in. Fig. 4C, when. 
25 a user sends a request 201 for a specific' form,, the 

associated form object 253 is called up and passed user 
559 and form 560 information. Form construct ionis 
•begun by selecting certain HTML fragments. . The form . 
object 253 then determines from the trial database 
30 including information about the- protocol version, . and 
from user privileges and patient information, which 
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sections are to be included, and those section objects 
are -then called by the form object to ' render themselves. 

As with the form object, each . sect ion obj ect has 
its own HTML fragments,- some of which are selected. 
5 This process continues, each object- in the hierarchy ' 
selecting HTML fragments according to' the user 
privileges, and " calling, its embedded obj ects . 

. Fig. 4D further illustrates how the HTML document 
211 is constructed dynamically from fragment templates 
10 and from data. A trial database '220 stores structural, 
information of the form object hierarchies as previously 
discussed. A descriptor, database 219 is essentially a 
library of HTML code fragments. These two databases 
, together make up the meta database 105. A clinical 
15 database 223 stores data collected during the trial.: 

'For example, the Demographics Form is described as 
having two sections, Section 1 and Section 2. In the 
preferred embodiment , pointers are used, such as the 
• pointer 230 to Section 1. Each section in turn has 
20 pointers to its items, and' so on.' 

Each part of the hierarchy also points to ". 
v corresponding code fragments in the descriptor database 
219. For example, the high level Demographics, form 
object comprises a pointer or identifier 231 which 
25 points to various code fragments 234. The object 
decides which fragments to use and which to reject, 
depending on user . rights. The selected template 
fragment is copied (indicated by 23 8) into the document 
211 . 

30 Each object in the hierarchy behaves similarly . 

Section 1 object data in the trial database 220 has a 
pointer 232 to its own corresponding code fragments in 
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the .descriptor database 2i9. Again, those code 
'fragments or templates selected, such as code fragment- 
235, are copied into the document 211/ as indicated by. 
arrow 239 . 

5 In addition, the object for Section 1 also has a 

pointer to data 236 stored in the. clinical database 223 
which is combined, in the output, document 211, as 
indicated by arrow 24 0, with, the fragment template 235. 
The data 236 is copied, as indicated by arrow 241, into 

10 the document 211, and replaces some placeholder from the 
original, fragment . . The copied data is indicated by 
reference 242. ■ 

Finally ,. the output document 211 is sent, ; or. 
published, to the requestor ,. whose browser renders the 

15 form. Arrow 243 demonstrates how one of the section 

fragments- with trial data is rendered into a section 204 
of. the form. 

Of course, the clinical data is initially entered 
by the CI/CRC arid stored, in the trial database when 
.20. submitted. Upon later retrieval for review or editing 

(assuming proper user rights), the. stored data "is filled 
in under. the data population process 209 (Fig. 3), 
wherein individual control or element objects retrieve, 
and. display actual clinical data from the clinical 
25 database 223. 

Note that while code fragments are generally in the 
form of HTML 'statements, they .can also contain small 
scripted statements written in a language such as . 
Javascript, which might be used to implement certain 
30 rules. For example, a. rule might allow patient 

temperatures only within a certain range, to protect 
against the entering of Celsius temperatures instead of 
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Fahrenheit. Checking with rules at the browser using a 

i 

language such as Javascript obviates the extra 
transmissions back and forth that would be required if., 
all checks were to be done' at the server. Such" rules 
5 may be based on the protocol which was active at the 
time certain data was entered. 

In. Fig. 4B, an inconsistency in the data has been 
found. The user has indicated in Question 7 that the 
patient has never smoked, yet in Question 9 has 
10 indicated - that the patient smokes cigarettes. Thus a 
query 271 has been entered by a CRA asking for further 
verification and appears on the form for the user to 
respond to. . 

. Finally, note that the text of each question is a 
15 link to additional information. For example, the text 
271 of Question 5, ''Weight" is a link to one of several 
. .'■ documents explaining weight in the context of the 
protocol. This is discussed further below. 

Fig. 5 illustrates how, in the preferred 
20 embodiment, .the same form can differ for a different 
user with a different role and. therefore different 
access rights. ' Here , User2 ' is a Clinical Research 
Associate (CRA) with the Sponsor. -The Sponsor is not 
. allowed to enter or alter data. Thus patient data at 
25 275 is simply displayed as text and is not editable. No 
controls are available. 

Note also that for User2 , different controls 277 
are provided in the application" layout panel 25 1A.. 
Here, there are two additional controls: Signatures and 
30- Monitor, because, these are CRA functions. Note. also 
that because the. form does not allow data entry, the 
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. . controls in pane 251C are also different from those of 

Figs . 4A and 4B . 

Preventing inadvertent use 

Fig. 6 illustrates a typical login screen of the 
5 present invention as displayed on a client browser. ' A 
user is asked to provide an account name 293 and a 
password 295. Upon clicking on the Log In button 297., 
•the account name and password are transmitted over the 
Internet to the Web Server 101 (Fig. 2) where they are .. 
.10 then submitted to the Application Server 103 for 

authentication. Alternatively, authentication could be., 
performed using alternative methods such as a secure' 
identification card, digital certificates or biometric 
characteristics. 
15 A preferred embodiment of the present invention 

displays -a photograph 257 (Fig. ,4A) for the purpose of 
discouraging inadvertent use of the system by another 
person. For instance, if the person logged in happens to 
. walk away for a break, ■ take a telephone call, etc. and -- 
. 20 another user comes along and logs in using, his .own 

login, and this second user takes a break, while the 
first user returns, the first user will see instantly 
that she is no longer logged in. A photograph catches 
the attention of the user much more readily than would a 
25 text-only name. 

In the preferred embodiment, the name and role 2 59 
of the logged- in user are provided under the photograph 
257. Thus, if the first user forgot to log out, a 
second user coming upon the system, and unfamiliar with 
30 the first user, could visually identify the first user, 
■ or if- unable to find the first user, because the name 
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is provided, could look the first user up in a directory 
if it were necessary to contact". the first* .user. : 

> - 
• Integrated DnRhhn^rH 

In a preferred embodiment, when the user has been 

5 authenticated, a. "dashboard" 301 customized to the, user ' 

is returned to the client browser and displayed. 

. Fig. 7 is a diagram illustrating the dashboard 

screen of the present invention." The dashboard 301 

. contains various information and links regarding the" 

10* study. For example, it contains study news 303 which 

the user should read and alerts 3 05 which may be 

critical. It also .contains study progress graphs 307,. a 

list of work to be completed 3 0 9 . with navigational 

links, and. additional information. It serves as a home 

15 base for the user. 

Intermedi ate Framps . 

While frames with curved corners can be 
aesthetically pleasing, HTML frames. do not provide such 
curved borders. Thus one aspect ■ of the present 

20 invention is the use of intermediate frames to provide 
the. curves . V 

Fig. 8 is a diagram illustrating the use of an 
intermediate frame by the present . invention . Normally, 
a Web display. may be broken down into several 

25 independent frames. . Here, Web page 400 is divided 

functionally into -three independent frames: a control 
panel frame 403, a content action panel frame 405 and a 
content panel frame 407. 

The developer of the Web site wishes to use a 

30 curved line 401 to visually differentiate the panels 
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from each other. However, in HTML, frame borders are 
■ limited to horizontal 'and' vertical lines. 

A preferred embodiment of the present invention 
simulates curved or irregular, shapes between frames by 
5 using an intermediate frame 409 between . frames 4 03 , 405 
and 4 07 in which the curves and other frame borders are 
drawn. Thus/ it appears to the user that the' various 
panels actually have curved borders. 

Bit. Mapp.ed Controls 

10 As discussed earlier, in a preferred embodiment of- 

the present invention, typical GUI controls which are 
normally executed in a stateful machine are implemented 
■ in a client browser. This; is done in the preferred 
embodiment of the present invention by- creating several 

15 bitmapped images which can be selectively placed such 
that the- browser properly constructs the desired ■ 
control. Bitmapped images may be formatted as gif, jpeg 
or other formats. Because browsers cache images 
locally, reuse of most of the . bitmaps in multiple 
• 20 control elements results in rapid construction, of the 
control element and thus the Web page. 

One advantage of this approach is that because many 
of the images are reused, only one copy of each needs to 
be . downloaded from the server. . Second, labels are' 

25 simple text and do not have associated images to be 
downloaded. The text is small and thus takes only a 
•short time' to transfer. Finally, because the image 
files corresponding to the bitmaps are locally cached by 
a browser, and because the image files are small, they 

30 consume only a small, portion of memory. 
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■ Fig. 9 illustrates this concept with a button 
control 501 containing the text label "ABC" 503. 
Ordinarily this entire button 501 is a single image. If 
many buttons are used, say having labels "DEF" , "GHI " 
5 and so on, each must have a completely different image, 
each requiring its own initial transfer time and its own 
cache storage. 

Instead, the present invention breaks the button 
image into several images 505A-505D. References or 
0 indications such as URLs to these images (which, in the 
preferred embodiment are generally "gif." files) are 
placed into a TABLE structure in an HTML document . Such 
a table 506 has five data entries, labeled 506A-506E. 
References to images 505A-505D are placed in four of the 
5 table entries 506A-5.06D, resulting in the placement by a 
browser, of the images . in the table 506, as indicated by 
arrows 509A-509D respectively. The label. text "ABC" is 

placed, with a background color matching the images 
505A-505D, into the remaining table entry 506E. 

Thus, while the application may use many different 
buttons, only the labels are different - the same images 
are reused by all of the buttons. No additional image 
files need to be transferred over the Internet. Only 
the text needs to be transferred and text takes but a 
fraction of the time an image takes to transfer. Since 
the images are reused, storage in the cache is much 
smaller as. well. 

Note also that an HTML- compatible browser 
automatically extends bitmapped images to fit a required 
space. Since a table adjusts itself to contain its data 
entries, a button 50 1A having a long label 503A (say the 
entire" alphabet) would be drawn having a label space 
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506E long enough to contain the , entire label . Table . 
entries 506B and 506C would be lengthened accordingly, 
and therefore . bitmapped images 505B and 50.5C would be 
. . extended to fill these lengthened entries, even though 
5 only minimal descriptions of the bitmaps is provided. '■ 
Below is sample HTML code to produce a button from 
several gif files. Bitmap images 505A-505D (Fig. 9) 
correspond to files named, respectively 
. "but_bot_left.gif"', v but_bot_top . gif " , 
10 u but_bot_right . gif " , and u but_bot_bot . gif " . The label 
of this particular button- is "Go". Note also that, each - 
of the table entries has the text: HREF= "tabs .htm" . 
Thus clicking anywhere on. the button will cause the 
browser to request a Web page identified as "tabs. htm" . 
15 <HTML> 

<!--////////////////////////////////////////////////// 
- - > 

<!--// Copyright (c) 1997-1998 Phase Forward Inc. 

.. . - - > . . ■ .. 

20 <]--// 51 Winchester Street, Newton MA 02161 

.,.--->. 

<!--// All Rights Reserved 

<!"////////////////////////////////////////////////// . 

•' ' ' 25 -> 

<HEAD> ' 
< STYLE > 

TD ' 

■ { . ' ... . . . : ; 

30 font-size: 8pt ; 

font -family: Arial, "Sans Serif"; 

text -align: center; 

vertical -align : middle; 

font-weight:- bold; 
35 color :#CCCCCC; 

TD . menu 

{. . . . 

- line-height: 10px; 
40 * ^ "height : 8px; 
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' } • 
TD.TDLeft 

• . { . ' •• ; 

text-align: left; 

'5 vertical -align : middle; 

} " 

TD.TDRight • 

• { . • . . • , ' . .• • 

text - align : - right ; 

10 -vertical-align: middle; 

} - • ' . . • 

A: link 

. { ' - - . - " v 

color: #CCCCCC; • . 

15 font-size: 8pt ; 

font -family: Arial, "Sans Serif"; 
font-weight: bold; 
text-align: center; \ 
text -decoration: none; " 

20 , } " . .:• . 

< /STYLE > 

</HEAD> 

<BODY> 

<TD NOWRAP TITLE="Click here to go to the patient 
25 visit" > 

. . < TABLE BORDER="0" CELLS PACING ="0" CELLPADDING= " 0 11 
. VALIGN= n middle" ALIGN= " lef t " > - 
" <TR> - 

<TD ROWSPAN="3 n NOWRAP >< A HREF= M tabs. htm" >< IMG 
30 .. SRG=" . / images /but__bot_JLeft .gif" 

BORDER= " 0 " x/Ax /TD> 
<TD NOWRAPxA HREF =" tabs, htm" >< IMG 

SRC=" . /images/but_bot_top.gif " WIDTH="34" 
: HEIGHT= "4 11 BORDER=»0"x/Ax/TD> ' 
35 ".. <TD ROWSPAN="3" NOWRAPxA HREF= " tabs . htm" >< IMG 

SRC=" . /images/but_bot_right . gif " 
• BORDER= " 0 11 ></A>< /TD> 
• </TR> . 
<TR> : 

40 <TD CLASS= "menu 11 BGCOLOR= u #3 3 6 69 9" NOWRAPxA 

HREF=" tabs, htm" >Go</Ax/TD> = 

</TR> 
<TR> 

<TD NOWRAPxA HREF= " tabs . htm" x IMG. 
45 SRC= n . /images/but_bot_bot .gif » WIDTH= " 34 " 

"HEIGHT= " 5 " BORDER="0"x/Ax/TD> . 
. , - </TR>- . 
'</ TABLE > 
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</TD> 
</BODY> 

Note that in HTML, a table structure, is delimited 
by the < TABLE > and < / TABLE >■ tags. Each row begins with 
5 the tag <TR> and optionally ends with ■ </TR> . Within 
each row, each column, or table data, begins with <TD> 
and optionally ends with </TD>. A COLSPAN=X or 
ROWSPAN=Y specification within a <TD> tag indicates that 
the corresponding entry is to -span X columns or Y rows 

10 respectively. 

Figs. 10A, 10B and IOC illustrate a file tab, or 
tab, control used by the present invention. Fig. 10A 
shows a tab control 421 having three tabs, although a 
tab control with any number of tabs can be implemented 

15 with this technique. As shown, the first tab element, 
labeled "ABC" is selected. 

The tab control 421 is subdivided into many small 
sections, shown' individually in Fig. 10C, each- of which, 
except for label sections, has a corresponding image. 

20 As with the button control , ,. many of the images are 

reused. . Each image has a shaded version and an unshaded 
version. A tab is shaded if it has been selected. For 
example, a right piece bitmap 437 , • a top piece bitmap 
42 5-, and a bottom piece bitmap 42 9 define most of the 

25 third U GHI" tab. The label- 435 is not a bitmap but 

rather, as with button labels described above, is simply 
. text with a background color to match the. surrounding 
bitmaps. Bitmap 431 is shared by the "GHIC" tab and the 
adjacent "DEF" tab. 

30 • The "DEF" tab uses the same top and bottom piece 

bitmaps 425, 429. Therefore, these bitmaps will not ■ 
have -to be. transferred again since they were just- 



WO 99/63473 PCT/US99/12406 f X : 

v > r 

-36- 

transferred in order to draw them into the "GHI" tab. 
Of course, the "DEF" tab here uses a unique label ' ' 
( "DEF" ) , but since that is simple text, it is placed 
directly in the table structure and as a result there is 
5 no significant overhead in its transmittal.. Another 
overlapping piece bitmap 4 3 1A is shared between the 
"DEF" tab and the selected "ABC" tab. 

The "ABC" tab uses shaded left, top and bottom 
piece bitmaps 423A, 425A, 429A respectively, to show 
10 that the. "ABC" tab is selected. The label "ABC" 427 is 
data embedded directly in the table data definition. 

Each of these small bitmap images has a HREF 
element assigned to it, i.e. a reference to send to the 
server if the user clicks the mouse button on the 
15 bitmap. Although the same top bitmap 425 is used for 

multiple tabs, each realization of the bitmap may have a 
different HREF assignment. Thus, for example, when the 
user clicks anywhere within any of the top 425 or bottom 
429 bitmaps or the label 427 associated with the "DEF" 
20 tab, information regarding "DEF" may be retrieved from 
the server and displayed on the browser. In addition, 
. the tab control appearance must change to indicate that 
"DEF" has been selected. 

Thus, the tab control now appears as shown in Fig. 
25 10B. Only two new images are required: the shared 

bitmap 431A between the "ABC" and "DEF" tabs has been 
replaced by a bitmap 439A with a different overlapping 
appearance, and the leftmost piece 423A is no longer 
shaded and must be replaced with piece 423 . These are • 
30 the only piece of the tab control that need to be 
provided by the server. 
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As with the button discussed above, without" this 
technique, it is necessary to. download and cache the 
entire tab control in each of its three possible states, 
i.e. three bitmap of the entire tab control; each with a 
5 different tab selected. This requires much more, cache 
memory than the present invention, as well as much more 
transmission time when the maps have not been cached 
(and each transmission, is a transmission of the entire 
tab control bitmap.) The present invention, on the 

.10. other hand, uses one small top bitmap 425 for each tab, 

as well as a bottom 429, left 423, and right 437 pieces,. 
. or their shaded versions 425A, 429A, 423A, 437A 

respectively, and right overlap 431A and left overlap 
439A pieces all of , which are significantly smaller than 

15 the whole. This difference becomes even more 

significant where the number of tabs is larger. As with, 
the button control, the top and bottom tab. bitmaps 425, 
429 respectively, can be extended and therefore the 
actual bitmaps are extremely small, just a few pixels 

.20 • wide and therefore consume a very small amount of cache 
memory . 

Another advantage ' to the present invention is that 
if the form changes so that the tab control has 
additional tabs, no further bitmaps need to be 

25 transferred. All of the necessary bitmaps will have 

been cached. Only the table structure with text labels, 
tab selection information, and references to the bitmap 
files needs to be transferred. 

Yet another advantage is that the present invention 

.30 . alleviates the need to create more images when a form 
changes. For example, in the prior art, if a tab 
control comprises seven individual tab control elements,' 
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seven different images must have been created - each one 
having a different tab selected. If it becomes 
necessary to add an eighth tab control element, eight 
new images must be created. In. the present invention/ 
5 no further images need. to be created. 

Preferably, these bitmaps are arranged by . placing 
them in a table, structure.' For example, the code below 
defines an HTML table . in which the positions .and files 
containing the bitmaps are specified. 

10 Also, in a preferred embodiment., the selected tab 

(whose associated form is displayed) is colored 
differently and rendered differently than the non- 
selected tabs . Thus there are different images for ' 
selected and non-selected tab parts. However, since a 

15 label is simply text and no image is used, a label's 
background color is specified within, the corresponding 
table entry to match the "tab. There is no image file, to 
be transferred.. 

The following sample code produces a file tab 

20 control with five tabs labeled "VS" , "LAB" , "AE" , "CM", 
. and "CMP" respectively , with "VS" indicated as the. 
selected form.. 

<HTML> 

< ! --////////////////////////////////////////////////// 

— > 

<!--// Copyright {c) . 1997-1998 Phase Forward Inc. 

— > - 

< 1 -—// 51 Winchester Street, Newton MA 02161 

— - > 

<!— // All Rights Reserved 

— > . 

<>■--////// ///////////////////./// ////////////a///////// 

— > ... 

<HEADr> 



25 



30 
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<META. HTTP- EQUIV=" Content -Type" content =" text /html ; 
charset=iso-8859-l"> 

<TITLE> Phase Forward Demo CRF Navigation' Bar</TITLE> 

< STYLE > 
5 BODY 

: { . •• ; • , 

margin- top : Opx; 
margin-left: Opx; 
margin-right: Opx;. 
10 margin-bottom: Opx; 

' . } ' • ' .• . • 

{ 

.vertical -align : bottom; 

15 } 

TD.tabselect 

. { . . " ■ • . . 

. color:. #FFFF00; 

font-size: 10pt;. . 
20 . font-family: Arial , "Sans Serif"; 

font-weight: bold; 
'text-align:, center; . 
vertical -align : center; 
line-height: 8pt ; 
25 height : llpt; 

" } • : - . :■ ■ • ' 

TD. tabnot select . 

{ . .. ; • •' ' * ' 

. color: #CCCCCC; 

30 font -size : lOpt ; 

font -family: Arial, "Sans Serif"; . 

font -weight: bold; 

text-align: center; 

vertical -align : center; ■ 
35 ; line-height : . 8pt ;. 

height : llpt ; 

} . . 

A: link 

■ {■ 

40 color : #CCCCCC; 

font-size: lOpt; 

font -family: Arial, "Sans Serif"; 
font -weight : • bold; 
text -decoration: none; 
"45 text-align: center; 

y 

A : visited 
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{ 

color: #CCCCCC; 
font -size: "lOpt; 

font-family: Arial , "Sans Serif " ; 
5 font-weight: bold; 

text-decoration: none; 
text-align: center; 

} 

A : hover 
10 { 

color: #FFFFCC; 

} 

</ STYLE > 
</HEAD> 

15 <BODY BGCOLOR= » #666666" > . 

<MAP NAME= 11 Of f MidMapl " > 

<AREA SHAPE="poly" HREF= " tab_vsbp . htm" . 
COORDS ="0', 1, 4 , 1, 10, 6, 15,20, 15,24, 0,24" 
TITLE= "Vital Signs/Blood Pressure "> 
20 <AREA SHAPE="poly n HREF= » tab_lab . htm" 

COORDS=" 27, 1,22, 1,17, 6,14,10,17,20,17,24,27,24, " 
TITLE= "Laboratory" > , 

</MAP> 

25 <MAP NAME- " OnMidLMap2 " > 

<AREA SHAPE="poly» HREF= " tabJLab . htm" 

COORDS="0,1 / 4,1,10,6 / 15,20,15,24,0.,24" 
TITLE= "Laboratory" > 

• </MAP> 

30 . 

<MAP NAME="OnMidRMap3"> 

<AREA SHAPE="poly" HREF= " tab_cm . htm" 

■ COORDS ="2 7-, 1,22,1,17, 6,14,10, 17,20,17,24,27,24, » 
TITLE=" Concomitant Medications " > 

35 </MAP> 

<MAP NAME= "Of f MidMap4 " > 

<AREA SHAPE="poly" HREF= " t'ab_cm. htm" . 
. COORDS="0,1,4,1,10,6,15,20,15,24,0,24" 
40 TITLE= "Concomitant Medications "> 

• -<AREA . SHAPE= "poly " HREF= " tab_cmp . htm" 

.COORDS="27, 1,22, 1, 17,6,14, 10,17,20,17,24,27,24, " 
TITLE=" Study Compliance " > 

</MAP> 
45 . - 
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< TABLE BORDER= " 0 " CELLPADDING- " 0" CELLSPACING- " 0 » . 
HEIGHT= " 10 0% " > 
<TR> 

<TD VALIGN- "bottom " x TABLE BORDER= " 0 11 
5 CELLPADDING- "O" CELLSPACING- " 0." ALIGN= " lef t »'■ > 

<TR> ' 

<TD ROWSPAN= n 3 n NOWRAPxA 
HREF- "tab__vsbp . htm" ><IMG 

SRC-" . /images/tab_of f_l . gif » BORDER= " 0 " 
10 ALT* "Vital Signs/Blood Pressure » x/Ax/TD> 

<TD NOWRAPxA HREF- » t ab_vsbp . htm" x IMG 

SRC-" . /images/tab_of f_top.gif " BORDER= "0 " 
WIDTH="52px H HEIGHT- 11 5 " ALT= 11 Vital 
Signs/Blood Pressure." x/Ax/TD> 
15 <TD ROWSPAN="3" NOWRAPxIMG 

SRC= n . /images/tab_of f_mid.gif " BORDER- " 0 " 
USEMAP- "#OffMidMapl"x/TD> 
<TD NOWRAPxA HREF- " t ab_l ab . htm " x IMG 

SRC- 11 . /images/tab_of f_top.gif " BORDER- " 0 " 
20 " ' T WIDTH="4 0px M HEIGHT-" 5" 

ALT- " Laboratory " x /Ax /TD> 
<TD ROWSPAN= M 3 n NOWRAPxIMG ' 
V- .SRC-" . / images /tab_on_midl . gif 11 BORDER- " 0 " 
USEMAP- » #OnMidLMap2".x /TD> 
25 <TD NOWRAPxIMG SRC- "./ images /tab_on_top . gif " 

BORDER- 11 0 " WIDTH- " 3 2px " HEIGHT-" 5 " 
ALT- "Adverse Experiences " x/TD> 
<TD . ROWSPAN- " 3 11 NOWRAPxIMG 

SRC-" . /images/tab_on_midr.gif " BORDER- " 0 " 
30 USEMAP- " #OnMidRMap3 " x/TD> 

. <TD NOWRAPxA HREF- " tab_cm . htm" x IMG 

SRC-" . / images /tab_of f_top.gif " BORDER- " 0 " 
WIDTH-" 34px" HEIGHT="5" ALT- " Concomitant 
Medications"x/Ax/TD> ' 
35 <TD ROWSPAN="3" NOWRAPxIMG 

SRC-" . / images'/ tab_of f_mid.gif " BORDER- " 0 " 
USEMAP- " #Of f MidMap4 " x /TD> 
<TD NOWRAPxA HREF- " tab_cmp . htm" x IMG . 

. SRC- /images/tab_of f_top.gif " BORDER-" 0" 
40 WIDTH- "43px" HEIGHT- "5" ALT- "Study 

Compliance " ></Ax/TD> 
<TD ROWSPAN- "3" NOWRAPxA 
.HREF-" tab_cmp . htm" x IMG 

SRC- ". / images/ tab_of f_r.gif " BORDER- " 0 " 
45 ALT- "Study Compliance" x /Ax /TD> 

</TR> 
<TR> 
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. <TD CLASS="tabnot select 11 BGCOLOR="#3 3 6699 M 

NO WRAP >< A KREF=" tab_vsbp.htm" TITLE= "Vital 
Signs/Blood Pressure" >VS/BP</Ax/TD> 
<TD CLASS= M tabnotselect " BGCOLOR= "#336699 " 
5 NOWRAPxA HREF=" tab_lab.htm" • 

TITLE= " Laboratory " >LAB</Ax/TD> 
<TD CLASS="tabselect " BGCOLOR= "#003366 " 

TITLE= "Adverse Experiences" NOWRAP>AE</TD> 

10 " • <TD" CLASS="tabnotselect BGCOLOR- "#33 6699" 

: NOWRAPxA HREF=" tab_cm.htm" - 

TITLE=" Concomitant Medications 11 >CM< /Ax /TD> 
" <TD CLASS="tabnotselect « BGCOLOR="#3 3 66 99" 

NOWRAPxA HREF= "tab^cmp. htm" TITLE=" Study 
15 Compliance" >CMP< /Ax /TD> 

</TR> . 
<TR> . - 

■ <TD BGCOLOR= " #33 6699 " NOWRAPxA 
. HREF="tab_vsbp.htm"xIMG 
20 SRC=" . /images/ tab_off_bot . gif" BORDER="0" : 

. WIDTH="52px" HEIGHT= " 5 " ALT="Vital 
Signs/Blood Pressure " x/Ax/TD> 
< TD BGCOLOR ="#336699" NOWRAPxA 
HREF= " tab__lab . htm" x IMG 
25 SRC=" . /images/ tab_off_Jbot .gif " B0RDER= " 0 " 

WIDTH="40px" HEIGHT= " 5 " 
• ALT=" Laboratory M >< /Ax /TD> . 
. .. <TD BGCOLOR="#003366" NOWRAPxIMG 

SRC=". /images/ tab_on_bot .gif " BORDER= " 0 " 
30 . . WIDTH="32px" HEIGHT= " 5 " ALT= "Adverse 

Experiences " x/TD> 
< TD BGCOLOR= " #336699" NOWRAPxA " 
HREF= " t ab_cm . htm " >< IMG 

SRC=" . / image s/tab_of f _bot .gif" BORDER = " 0 " 
. 35 WIDTH= " 34px" HEIGHT = " 5 " ALT=" Concomitant 

Medications " x /Ax /TD> 
<TD BGCOLOR="#336699" NOWRAPxA. 
HREF=" tab_cmp.htm" xIMG 

SRC= " . /images/ tab_.of f _bot . gif " BORDER= " 0 11 . 
'40 WIDTH= " 43px" HEIGHT= " 5 " ALT="Study 

• • ' Compliance" x /Ax /TD> 

- <TD VALIGN= "bottom" COLS PAN= » 3 " NOWRAPxIMG 

SRC=" . /images/tab_of f_bot .gif " WIDTH= " 1000 " 
HEIGHT= " 5 " • B0RDER= " 0 " x /TD> 

45 </TR> 

< /TABLE x/TD> 
</TR> 
• < /TABLE > 
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</BODY> 
</HTML> 

The correlation between bitmaps from Fig. IOC and 
their corresponding file nam.es is given in the table 
5 below : ■ 



F.ig. IOC ref . number 


Filename in HTML, rode 






423A / 423 


tab_on_l.gif / tab_of f _1 . gif 


425A / 425 


tab_on_top.gif / tab_off_top.gif 


42 9A / 42 9 


tab_on_bot.gif / tab_off_bot.gif 


431A 


t ab_on__mi dr . g i f 


439A 


tab_on_midl.gif 


437A / 437 


tab_on_r.gif / tab_off_r.gif 



Similarly, Figs.. 11A, 11B and 11C illustrate a 
linear control, preferably a time-line control, of the 

15 present invention using the same technique. Fig. 11C 
shows the various bitmaps that are placed. in a table 
structure to compose a linear .control.. The dashed lines 
show the outline of the bitmap, while the solid lines 
represent what is actually seen... Of course, color and. 

20 shading can be used to produce a more' dramatic effect,' 
and in fact are used in the preferred embodiment. 

Bitmap 481 defines the left end of the control and 
shows the left" end of a frame which encloses the 
control. Similarly bitmaps 482, 483 and 489 define top, 

25 bottom and right frame pieces respectively of the 

control enclosure. Note that -by defining a bitmap to 
span multiple rows or columns within a table entry does 
not change, the appearance of the bitmap except to extend 
it in the vertical or horizontal direction respectively. 
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Bitmaps 483, and 485-488 define the various parts 
of the linear control it self . ' Bitmaps 483 .and 488 are 
the left and right pieces respectively of the control 
and in the preferred embodiment are only used once per 
5 control.- Bitmap 485 is the line part of the' control and 
is used simultaneously in several places. Bitmap 4 86 
has a continuation of the control line, plus a vertical 
tick. Bitmap 487 is used to show which value has been 
selected. 

10 These bitmaps 481-439 can be assembled -in various 

combinations to create linear controls of any size, and- 
to show any control in any particular state. For 
example, in Fig. 11A, bitmaps 481-489 (from Fig. 11C) 
have been assembled into a table 451 to create a linear 

15, control with four stops. In addition, labels have been 
placed in the table below each stop. These labels are 
merely t^ext- entries with a background color matching the 
control, so that there is negligible overhead in 
obtaining the labels. • 

'. The following HTML code produces the linear control, 
of Fig. 11A. 



20 



30 



<HTML> ' 

< I "/////////////////////■///////////////////////////// 

— > 

25 <!--// Copyright (c) .1997-1998 Phase Forward Inc.' 

— > 

<*•'-// 51 Winchester Street, Newton MA 02161 

— > ' 

*--// All Rights Reserved 

////////////////////////////////////////////////// 



> 

< 

- - > 

- - > 



<HEAD> 



<META- HTTP-EQUIV= "Content -Type" content =•< text /html ; 
35 char^et=iso-8859-l u > 

<TITLE> Phase Forward Demo Visit Bar</TITLE> 
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< STYLE > 
BODY 
{ 



margin- left :• . Opx; 
5 . ..margin-top: Opx; 



TD 



font-size: 8pt ; 
10 -font -family :. Arial , " Sans Serif";. 

font-weight: bold; 
• \ -text -align: center;' 

vertical -align : middle; 

} 

15 TD.tdselect 

{ ; ' - 

color: ■ #FFFF00; ■ 

} 

- A: link 

20 {-"'*'* 

color: #CCCCCC; 
• font-size: '8pt ; 

f ontr family :. Arial, "Sans Serif"; 
font-weight: bold; 
25 text-decoration : none ; 

text-align: center; 
'vertical -align : middle; 
line-height : llpx; 
. height : 8px; 

30 } 

A : visited 

{ 

color: #CCCCCC; 

font -size :' 8pt 
35 font-family.: Arial, " Sans' Serif " ; 

font-weight: bold; ■ 
"text-decoration:, none ; 

text-align: center; 

vertical -align : middle; 
40 line-height: llpx; 

height : 8px; 

} . ' • • 

A: hover . . 

{ 

45 color: #FFFFCC; 

} 

TD.tickmark 
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vertical -align ; middle; 
/*line-height : 12px; 
height: 12px;*/ 

} 

5 </STYLE> 
</HEAD> 

<BODY BGCOLOR= " #33 66 9.9 " > 

' < TABLE BORDER= " 0 11 CELLPADDING= 11 0 " CELLS PACING= " 0 " 
HEIGHT= n 100%" ALIGN= n left « VALIGN= " top" > 
10 <TR>' . 

<TD ROWSPAN= n 3 " ><IMG 

SRG= " . / images/ tick__indent__l . gif 11 
BORDER= " 0 " ></TD> 
• <TD COLSPAN="2 " ><IMG ... 
15 SRC=" . /images/tick_indent_top.. gif '" BORDER= 11 0 " 

WIDTH= "53 n HEIGHT= 11 5 ">< /TD> 
<TD COLSPAN= n 3 11 xIMG 
. SRC=" . /images/t ick__indent_top . gif " BORDER=" 0" 
WIDTH="7 0" HEIGHT= ,, 5 ,l x/TD> 
20 ' <TD. COLSPAN= n 3 n ><IMG 

SRC=" . /images/tick_indent_top .gif " BORDER= 11 0 " 
WIDTH="70" . HEIGHT= ,, 5 l, x/TD> 
<TD COLSPAN=".3"><IMG 

" SRC=" . /images/tick_indent_top.gif 11 . BORDER= n 0" 
25 WIDTH=" 70" HEIGHT="5 ,, x/TD> 

<TD COLSPAN="3 " xIMG 
■' SRC= n . /images/tick__indent_top;. gif " BORDER= 11 0 " 
WIDTH="70 U HEIGHT= n 5"x/TD> 
<TD COLSPAN="3"xIMG - 
30 SRC= n . /images/tick_indent_top . gif " BORDER^ " 0 " ■ 

WIDTH= H 70 " HE I GHT - " 5 " x / TD > 
<TD COLSPAN= n 3 n xIMG 

SRC= n . /images/tick_indent_top . gif 11 BORDER= ,, 0" 
. WIDTH="7 0" HEIGHT= n 5"x/TD> 
35 <TD COLSPAN="2 M xIMG 

SRC=" . /images/tick_indent_top . gif " BORDER= ,, 0 ,t 
WIDTH= n 46" HEIGHT^ 1 ' 5 " ></TD> 
<TD ROWS PAN = n 3 " xIMG 

SRC=" . /images/tick_indent_r .gif " . 
40 BORDER= " 0 " x/TD> 

</TR>- 
<TR> \ 

<TD CLASS= n tickmark" xA HREF= " tl_jwk- 4 . htm" ' 
TITLE-" '•>< IMG SRC=V./images/tick_left .gif V 
45 BORDER= " 0 " x /Ax/TD> 
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<TD CLASS="t ickmark" xI.MG 

SRC=" . /images/tick_line .gif " BORDER= " 0 " 
WIDTH="35" HEIGHT= " 3 " ></TD> 
.<TD CIASS="tickmark"xIMG. 
5 SRC= n . /images/tick_line ..gif »' BORDER= " 0 " 

WIDTH= ,r 2 6" HEIGHT="3"x/TD> 
<TD CLASS="t ickmark "xA HREF= " tl_wk-2 .htm" 

TITLE= " "><IMG SRC=" . / images/ 1 i ck_middle . gif '» 
BORDER= " 0 " x/Ax/TD> 
10 <TD CLASS= "t ickmark" xIMG . 

SRC=" . /images/tick_line .gif " BORDER= " 0 " 
WIDTH= M 26 n HEIGHT= "3 " x/TD> 
<TD CLASS=" t ickmark" xIMG 

SRC=" . / images /tick_line . gif " BORDER= " 0 " 
15 WIDTH="2 6" HEIGHTS "3 " x/TD> 

<TD CLASS= H tickmark ,, xA HREF="tl_wkO .htm" 

TITLE= " 11 xIMG SRC= U . / images/ tick_middle .gif " 
BORDER= " 0 " x/Ax/TD> 
„. <TD CLASS = " t ickmark " x IMG 
20 . - ' SRC=" . */images/tick_line.gif ■' BORDER="0" 

WIDTH="2 6" HEIGHT=" 3 " x/TD> 
<TD CLASS = " t ickmark" xIMG . 

SRC=" . /images/tick_line . gif " BORDER=" 0 " 
WIDTH="26" .HEIGHT = " 3 " x/TD> 
25 . <TD -CLASS= n tickmark" xA HREF= 11 tl_wkl . htm" 

. TITLE= 11 11 xIMG SRC=" . /images/tick_middle . gif 11 
BORDER= " 0 " x / Ax /TD> 
. ■ <TD CLASS = "t ickmark '» x IMG 

SRC= " . / images/ tick line . gif " BQRDER= " 0 " . 

30 WIDTH="26" HEIGHT= " 3 " x/TD> 

<TD CLASS="t ickmark" xIMG 
: SRC=". /images/t ick_line.gif " BORDER = " 0 " 

WIDTH = "26" . HEIGHT= 11 3 11 ></ TD> 
<TD CLASS= n t ickmark" xIMG 
35 " SRC=" . / images /tickjniddl e_selected.gif » 

B0RDER= " 0 " ></TD> 
<TD CLASS="t ickmark" xIMG 

SRC=" . /images/t ick_line.gif " BORDER= " 0 11 - 
WIDTH="26" HEIGHT = " 3 " x/TD> 
40 <TD CLASS="t ickmark" x IMG 

SRC=" . /images/t ick_line.gif " BORDER = " 0 " 
WIDTH="26" HEIGHT- " 3" ></TD> 
<TD CLASS="t ickmark "xA HREF= " tl_wk4 . htm" 

TITLE= " "xIMG SRC=" . /images/ tick_middle . gif " 
45 BORDER="0"x/Ax/TD> 

<TD CLASS="tickmark"xIMG 

SRC= M . /images/tick_line .gif " BORDER= " 0 " . 
WIDTH="26" HEIGHT= n 3 " x/TD> 
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<TD CLASS= n tickmark ,, xIMG 

SRC=" . /images/tick_line .gif " BORDER= " 0 " 
W-IDTH= ,, 26" HEIGHTS "3 " x/TD> • 
<TD' CLASS="tickmark"xA. HREF="tl__wk5 .htm" 

TITLE=»"xIMG SRC=" . / images/ tick_middle . gi f 11 
BORDER= " 0 " x /Ax/TD> 
<TD CLASS="tickmark" ><IMG 

SRC="'. /images/tick_line . gif " BORDER = " 0 " 
. WIDTH="26" HEIGHT="3"x/TD> 
<TD CLAS'S=' , tickmark u xIMG 

SRC=" . / images /tick_line . gif " BORDER- " 0 " 
WIDTH- "28" HEIGHTS" 3" x/TD> 
<TD CLASS = "tickmark"xA HREF- " t l_wk8 . htm" 
. TITLE=" "><IMG SRC-" . / images/tick_r ight .gif " 
BORDER- " 0 "' x /Ax /TD> 

/TR> 
TR> 

<TD COLSPAN="2 n xIMG 

SRC- " . / images /tick_indent_bo't . gif " BORDER- " 0 " 

WIDTH- "53" HE I GHT= 11 5 11 >< / TD > ■ " 
<TD COLSPM= ,, 3"xIMG 

SRC-" . /images/tick_indent__bot . gif " BORDER- " 0 " 

WIDTH="70 fl HEIGHT= ,, 5 n x/TD> 
<TD COLSPAN="3 "xIMG '. 

SRC-" . /images/tick_indent_bot . gif 11 BORDER- " 0 " 

WIDTH="70" HEIGHT="5" x/TD> 
<TD COLSPAN-"3 " xIMG 

SRC=" : /images /tick_indent_bot .gif " BORDER-" 0" 

WIDTH- "7 0" HEIGHT- " 5 " x /TD> 
<TD COLS PAN- "3"> < IMG 

• SRC- " . /images/ tick_indent__bot'. gif " BORDER- " 0 " 

WIDTH= !, 70" HE I GHT- "5 M ></ TD > 
<TD COLSPAN= 11 3 11 xIMG . 
. SRC-" ../images/tick__indent__bot .gif 11 B0RDER= "0 " 

WIDTH- "70" HEIGHT- " 5 " x /TD>. 
<TD COLSPAN= !, 3 " xIMG . 

SRC= n . /images /tick_indent_bot .gif" BORDER- 11 0 11 
• WIDTH ="70" HEIGHT- "5 " >< /TD> 
• <TD COLSPAN="2"xIMG 

SRC-" . /images/tick_indent_bot . gif " BORDER-"0"- 

WIDTH="46" HEIGHT- » 5" x/TD> ' 

/TR> 
TR> 

<TD COLSPAN="3 n STYLE= ' text -align : left ' 

BGCOLOR- "#33 6 6 99" NOWRAPxA HREF- " t l_wk- 4 . htm 
TITLE-" Placebo Run- In Visit 1 " >  Week 
I 1 –4</Ax/TD> 
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<TD C0LSPAN="3" BGCOLOR= " #3.3 6 6 9 9 " NOWRAPxA 

HREF="tl_wk-2 .htm"' TITLE=" Placebo Run- In Visit 
2" >Week &#8211 ; 2</Ax/TD> 

<TD COLSPAN="3" BGCOLOR= » #3 3 66 9 9 " NOWRAPxA 
5 HREF= ,u tl_wkO .htm" TITLE= "Baseline Visit">Week 

0</Ax/TD> 

<TD COLSPAN="3" BGCOLOR= " #3 3 6 6 9 9 11 NOWRAPxA 

HREF=" tl_wkl.htm" TITLE= " Treatment Visit l">Week 
" 1</Ax/TD> 

10 <TD COLS PAN = " 3 " CLASS="tdselect " ' BGCOLOR = "#336699" 

TITLE=" Treatment Visit 2" NOWRAP>Week 2</TD> 
<TD COLSPAN="3" BGCOLOR= " #33 66 99 " NOWRAPxA . • 

HREF="tl__wk4 .htm" TITLE= " Treatment Visit 3">Week 
• 4</Ax/TD> . 
15 • <TD COLSPAN="3" BGCOLOR= " #3 3 6 6 9 9 " NOWRAPxA 

.HREF="tl_wk5 .htm" ' TITLE= " Treatment . Visit 4 . 
(Optional ) " >Week 5</Ax/TD> 
<TD COLS PAN = " 3 11 STYLE= 1 text - align : right V 

BGCOLOR* "#3 3 6699" NOWRAPxA HREF= " t l_wk8 . htm" 
20 TITLE= " Final Visit " >Week; 8</Ax/TD> 

</TR> . 
< /TABLE > 

' </BODY> * 
</HTML> 



25 Note ".in addition that certain table- entries have!', 

anchors, denoted by the <Ax/A> element pair. An HREF 
specification within an <A> element specifies the source 
of * a • document -of " image file.- - Those parts of the control 
corresponding to table entries having anchors with HREF 

30 specifications will; cause . a message to be sent to the 

server , when a user clicks in the. entry area., requesting 

- . the specified document. The server . processes that 
request , returning pertinent information about the 
selected week in the form, and at the same time, 

35 resending the table with the references to the image 

files reordered so that the control will appear with the 
user's selection, selected and with a form appropriate 
for a particular visit. Thus the control appears to 
work" -as the user would normally expect, yet all of. the 
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work is done at the server. In addition, none (or at 
most one) of the bitmaps need to be downloaded because 
they have already been used and should be cached at the 
browser. Thus the transmission from. sender, to client 
5 will not be -hampered by a need to download- many bitmaps . 

Without the present invention, it is necessary to 
download ..from the server a very large- bitmap comprising, 
the entire control' in a particular state, -say with the 
first tab selected. For each state having .a . different 

10 tab selected, a separate, large bitmap of the entire tab 
control must be sent from the server if not already - 
cached, and when these large bitmaps are cached, each 
consumes a very large amount of available cache memory. 
Fig. 11D illustrates a variation of the time-line 

15 control 490 in which the time-line is further subdivided 
with , small ticks 491 which do not have their own 
associated labels, yet each is associated with a 
different copy of a bitmap and a HREF. For example, the 
ticks 491 may represent . weeks within a month.. Because 

20 each tick 491 has its own bitmap, the' user can click on 
one to move the pointer" 4"92 to a particular week. : 

Finally, -in a further embodiment of 1 the present 
invention, an individual bitmap may itself be sectioned/ 
each section being mapped to a different indicator or 

25 • URL , or.no URL at all. For example, . the ' file tab HTML 
code above uses HTML tags <USEMAP>, <MAP> and <AREA> to 
specify two different. URLs corresponding to the left tab 
. and right tab within the . tab_off_r bitmap " That part of 
the bitmap not corresponding to any tab is not. .mapped to 

30 an URL. 

Protocol - version riepend<=mf formg 
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. For various reasons, it is common during a trial 
for- the • protocol to undergo changes. Related forms must 
be changed to fit the • new protocol when this happens. 
However data entered before" the change, i.e. in the old 
5 protocol, must be presented in a form corresponding to 
the old protocol under which it was entered." 

In addition, as stated earlier, a protocol change 
may need to be reviewed by an Institutional Review Eoard 
at .each site before it can be implemented. This can . 
10' result in there being two or more active protocols at 

the same. time. Again, the data must be presented in the 
form, corresponding to the protocol in which the data was 
entered . 

- Fig.. 12A is a flowchart illustrating the process: at 
15 the server in deciding how to.- deliver a form to the 

browser depending on the study protocol version control. 
At block- 601, a request is received from a client. . The 
server determines what the correct study- protocol 
version should be for the request based on date and time 
20 by looking up' the protocol version of the CRF when data 
was. first entered in the CRF.. At block .605, the server 
determines whether the necessary form .(CRF) already 
exists. If so the form is loaded . and populated with the 
correct data (block 607). Otherwise, the. form is 
25 created (block .609) . Finally, in block 611, the correct 
populated form is. returned to the requesting client. 

Figs, .12B and 12C illustrate a CRF as it might 
appear in a first protocol (ref . 620 in Fig. 12B) .and as 
• it might appear in a second protocol (ref. 622 in Fig. 
30 12C) .. In Fig. 12B, the CRF 620 has three items 621, 

•623, 625. Perhaps at the beginning of the trial, it . was 
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established that blood pressure, would be measured twice 
and entered into items 623 and 625. 

At. some point during the trial, it is decided to 
change the protocol so that blood pressure is to be 
5 measured three times. The CRF would then appear as in 
ref. 622 in Fig. 12C, having an additional item 627 
corresponding to the new third measurement. 

Of course, for visits occurring prior to the 
protocol version change, there would only be two blood 
10 pressure measurements on file, and so the CRF as .- 
portrayed in Fig. 12B (ref. 620) ■ is retrieved, and 
displayed when a user examines those visits. 

Integrated help 

In prior art applications, help is often available 

15 in the form of a help button, or a help link. 

Typically, the user clicks on the help button or link, 
and a general help page, often accompanied with a table 
of contents and/or a topic index, is retrieved - from the 
server and - displayed, replacing the" .original page. To . < 

20 find help, the user must search through the table of 

contents or the index, sometimes through several layers. 
To return to the original page,, the user must either. go 
back by clicking on a "Back" button in the browser,, or 
optionally by clicking on a "Back to Document " -type link 

25 or button that is typically available on the help page. 
Several steps are thus required to obtain help about a 
specific topic and then return to the original page for 
which help was needed. 

An innovative aspect of the present invention is 

30 the use of context sensitive help in a Web document. As 
seen 'in Fig. 13A, the text of each question comprises a 
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' link to one of several trial-related documents. For 
instance, the text 801 "Height " . f or item 4 is such : a 
link. When the user clicks on the text 801, a separate 
help window 80.3 pops open, as in Fig. 13B, and context 

. 5 sensitive help 804 is transferred from the server and 
displayed in the help- window 803. This context 
sensitive help 804 has information specific to the text 
801 clicked on - here there are specific instructions as 
to how to measure height, e.g. shoes off. Thus the user 

10 does not have to look for the subject in' an index or 
table of contents, and the original page is still 
' available - the user can close the help window at any- 
time and the original page has not been affected. 

Preferably, help comes from one of three standard 

15 sources defining' the clinical trial : a protocol 

document, an investigative brochure, or a study guide. 
Note that the help window 803 comprises additional 
button controls 805 which enable the user to go directly 
to related information in any of the three documents". 

20 In addition, a help button 807 is always available 

in the main panel 251A. Clicking on this button 807 
brings up a general help window 809, from which a user 
can browse through a table of contents 810 or an index 
811 for the clinical trial documents. Again, additional 

25 buttons 805 allow the user to choose a specific 

document. Figs. 13E and 13F show sample help screens, 
for the protocol- document 811 and study guide 812 
respectively. 

EQUIVALENTS 

30 While this invention has been particularly shown 

and- described with references to preferred embodiments 
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thereof, it will be understood by those skilled in the 
art that various changes in form and details may be made 
therein without departing from the spirit and scope of 
the invention as defined by the appended claims. Those 
5 skilled in the art will recognize or be able to 

ascertain using no more than routine experimentation, 

many equivalents to .the specif ic embodiments of the 
invention described specifically herein. Such ' 
equivalents are intended to be encompassed in the .scope 
10 of the claims . 
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, CLAIMS 



What is claimed -is : 



1. A method of constructing a graphical user interface 

(GUI) application, comprising the steps of: 
.5 . creating a protocol database which is specific 

to an application for which data is input and 
displayed through a client browser, and a data 
database which is specific to a subject processed . 
by the application; 
10 generating a template based on the. protocol 

database and a context received from the client; . 

populating the template with application data 
from the data database; and 

publishing the populated template via a- . 
15 content server to the client . browser as an SGML- 

derived form for input and display, of data for the 
application. 

2. The method of Claim 1 wherein generating the 
template is further based on the data database. : 

20 3 . The method of Claim 1 wherein the protocol database 
is. based on a clinical protocol.. ' 

4. The method of Claim 1 wherein. the template 

comprises a plurality of frames including control 
frames comprising one or; more control elements, and- 
25 ^ -an intermediate frame presenting a visual attribute 
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shared by the control frames, appearance of the 
intermediate frame depending on .visual states of 
the control frames. 

5. The method of Claim 1, wherein generating the 
5 template further- comprises': - 

creating a plurality of bitmaps which 
. selectively and in combination may be constructed 
to present a GUI control element in plural states; 
specifying the template as , a Standard 
10 Generalized Markup Language (SGML) -derived 

document ; 

and. placing the bitmaps within the template 
such that. upon receipt of the document at the 
browser, the browser will display a desired GUI 
15 control ... 

6. The method of Claim 1 , further comprising 

changing a' first- protocol version to a second 
protocol version; . and wherein 

generating a. template is further based. on a 
20 protocol version which was active at time of 

" entering data to be displayed. 

7. A method of entering clinical trial data from a 
client, whereby the data is maintained on: a server, 
the method comprising: 

25 defining a first protocol, under which the 

clinical trial is to be run; • 

allowing the first protocol to be changed to a 
second protocol anytime during the trial; and 
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displaying a form at the client, wherein the 
form is based on a protocol which was active at 
time of entering data to be displayed in the form. 

8. • The method of Claim 7 wherein the form is selected 
5 from a library of, forms. 

9. The method of Claim 7 wherein the form is 
dynamically generated. 

10. The method of Claim 7 wherein rules associated with. 
• ' the displayed form are based on the protocol 

10 version which was active at the time of entering 

data to be displayed in the form. 



11. A clinical trial data entry method, .comprising: 

...displaying a form on a computer screen, the 
form having at least one question to which a user 
15 must respond to provide clinical data; 

creating links between text of each question 
and detailed information related to the question; 
and 

• if the user clicks on text of the question, 
20 displaying detailed information corresponding, to 

the question. 

12. The method of Claim 11 wherein the detailed 

• information displayed is a help document defining 
the clinical trial. 
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.The method of Claim 12 wherein the help document - i< 
one of a protocol' document, an investigative 
brochure, .and a study guide. • 

The method of Claim 12 wherein the help document • 
comprises all of a protocol .document/ an 
investigative . brochure, and a study guide. 

A clinical trial data- entry method, -comprising: 
displaying, a form on a computer screen, the 

form .having at least one question to which a user 

must respond to provide clinical "data ; 

upon, a user request , displaying detailed 

information from any or all of a protocol document, 

an investigative brochure, and a' study guide. 

The "method of Claim 15 wherein the user can- walk 
through each of the protocol document , 
investigative . brochure and study guide. 

The method of Claim 16 wherein the detailed 
information- displayed is ' from a section of the 
protocol document,' investigative brochure, or study 
guide, which. sect ion pertains immediately to the 
question to which the user must respond. 

A method/of .constructing .a graphical user interface 
(GUI) clinical trial application, comprising the ; 
steps of : 

providing a user login procedure;, 
upon a user logging in, presenting to the user 
a" dashboard screen comprising information regarding 
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the trial, the dashboard screen. being customized 
for the user. 

19. The method of Claim 18 wherein the information 
comprises trial -related news.. 

5 20. .The method of Claim 18 wherein the information 
comprises alerts. 

21. The method of Claim .18 wherein the information 
comprises statistical information. 

22. The method of Claim 18 wherein the information 
10 comprises progress reports. 

23. The method of Claim 18 wherein the information 
comprises a list of work . to be completed. 

24. A method of implementing a graphical user interface 

(GUI) control element within a client browser, 
15 comprising the steps of : 

creating a plurality of bitmaps which -> 
selectively .and in combination may be constructed 
to present the . GUI control element in plural - 
states ; 

20 specifying placement of the bitmaps within a 

, Standard Generalized Markup Language (SGML) -derived 
document such that upon receipt of the document at 
the browser, the browser will- display a desired GUI 
control 
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25. The method of Claim 24 wherein the step of 

• specifying placement of the bitmaps further 

comprises the step of placing indicators to the bit 
maps in certain locations within the document, such 
5- that the browser will correctly .display the control, 

element . 

26. The method of Claim 25 wherein the indicators are - 
uniform resource . locators (URLs) . 

27.. The method of Claim 25 wherein the certain. 
10 locations, are table entries. 

28. The method of Claim 24 further comprising the steps 
of: 

partitioning a bit map into multiple sections; 

and " 

15 associating each section with a different 

indicator. 

29. The method of Claim 24 wherein the desired control 
. element is a file tab control / comprising a left 

piece, bitmap/ a right piece 'bitmap, and a center 
20 piece bitmap. . 

30. The method of Claim 29 wherein- left and right 
bitmaps of adjacent right and. left control elements- 
are shared . 

31. The method of Claim 24 wherein a desired control is 
25 a linear control, further comprising: 
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button control; elements . spaced at intervals 
. along a line, wherein each button control element 
• ' is a bit map or combination of bit maps; and 

a, pointer to indicate a current value along 
5 the . line . 



32. The method of Claim 24 wherein the SGML-derived 
• - document is. in HTML. 

■33. The method of Claim 24 wherein the SGML-derived 
' document is in XML. 

10 34. The method of Claim 24 wherein the server is 
stateless with respect to the GUI control . 

35. The method of Claim 24 wherein at . least one bit map 
is used by a plurality of similar GUI controls. 

36. - A method of entering clinical trial data from a 

15 .client, whereby the data is. maintained on a server/ 

the method comprising: 

generating, at the server, a data entry form 
to be displayed at the client, the data entry form 
being generated dynamically in a SGML-derived 

20 language, control elements within the form 

comprising bitmaps . which selectively and in 
combination construct the control elements, 
individual bitmaps being used within the plural 
control elements . 



25 



•37. The method. of Claim 36, further comprising: 
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displaying, at a client, selected- clinical 
trial data based on any or all of a user, a 
patient, a protocol version' within a clinical 
trial, and data previously entered. 

38. The method of Claim 36 further comprising: 
creating a protocol database which is specific 

to an application; ' 

creating a data database which is specific to 
a .subject processed by the application ,- 

generating the form based on the protocol 
. database and a context received from- the ..client ; 

populating the form with application data from 
the data database; and 

publishing the populated form to. the client : 
15 browser . 

39. A method of discouraging' inadvertent use of a ' 
computer application, comprising: 

requiring an authentication procedure ' for each 
user; and 

20 displaying .a picture of an authenticated user . 

40. • A system for constructing . a graphical user . 

interface (GUI) application, comprising: 

a protocol database which is specific to an. 

application for which data is input* and- displayed • 
25 through a client browser; ' 

a data database which is specific to a subject 

processed by the application; 
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a template generator which generates a 
template based on the protocol database and a 
context received from the client; 

a template populator which populates the 
5 template with application data from' the data 

database; and 

a content' server which publishes the populated 
template to the client browser as an SGML-derived 
• form for input and display of data for the 
■ 10 'application. 

41. The system of Claim 40 further comprising: 

a plurality' of frames, some of ' the frames 
being control frames comprising one or more control 
elements, other frames being intermediate frames to 
15 be shared by the control frames, appearance, of the 

intermediate frames depending on visual states of. 
the. control, frames. 

. 42. A computer system for entering' clinical trial data, 
comprising: 

20 a form displayed on a computer screen, the 

form having at least one question to which a user 
must- respond to provide clinical data; and 

links between text of each question. and . 
detailed information, related to the question, the 

25 detailed information existing in at least .one on- 

line document, such that if the user clicks on text 
of the question, displaying detailed information 
corresponding to the question is displayed. 



BNSDOCID: <WO 9963473A2_I_> 



WO 99/63473 



-64- 



PCT/US99/12406 



43. A system for implementing a graphical user 

interface (GUI)' control element within a client 
browser, comprising: 

construction means for constructing the GUI 
5 control element in plural states from a plurality 

of bitmaps ; 

placement means for placing the bitmaps within 
a Standard Generalized Markup Language (SGML) - 
derived document such that upon receipt of the 
document at the browser, the browser will display a 
desired GUI control. 



10 



44 . 



15 



20 



25 



The system of Claim 43 wherein placement means 
further comprises a table means for placing 
indicator means to the bit maps in certain 
locations within the. document , such that the 
browser will correctly display the control element 

45.. A system for constructing a graphical user 
interface (GUI) application, comprising: 

protocol database means specific to an 
application for which data is input and displayed 
through a client browser, and data database means 
which is specific to a subject processed by the 
■ application; 

' generation means for. generating a template 
based on the protocol database means and a context 
received from the client; 

template populating means for populating the 
template with application data from the data 
database means;, and- 
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publishing means for publishing the populated 
template via a content server to. the client: browser 
as an SGML-derived form for input and display of 
data for the application. 

5 46. A system for implementing a graphical user 

interface (GUI) control element within a client 
.browser, comprising: 

a plurality of bitmaps which, selectively and . 
in combination may be constructed to present the 
10 GUI control element in plural states; 

. a Standard .Generalized Markup Language (SGML) - 

derived document in which placement of the bitmaps 
is specified such that upon receipt of the document 
at the browser, the browser will display a desired 
15 . GUI control 

47. The system of Claim 46 wherein , placement of the 
bitmaps is specified by placing indicators to the 
bit maps in certain locations within the document, 
such that the browser, will correctly display the 

20 control element. 

48. The system of Claim 47 wherein the indicators are 
uniform resource', locators (URLs) . 

49. The system of Claim 47 wherein the certain 
locations are table entries. 

25 50. The .system of Claim 46 wherein a bit map comprises 
multiple sections, each section being associated 
„wjLth a different indicator. 
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51. The system of Claim 46 wherein' the SGML-derived 
document is in HTML. 

52. The system of Claim 4 6 wherein the server is 
stateless with respect to the GUI control. 

5 53. The system of Claim 46 wherein at least one bit map 
. is used by a plurality . of . similar GUI controls... 

.54. A system for entering clinical trial data from a 
client, where the. data' is maintained on a server, 
the system comprising: 

a data entry form- generator to dynamically ' ' 
generate a form in a SGML-derived language, the 
form- to be displayed at the client , control, 
elements within the form comprising bitmaps which 
. selectively and in. combination construct the 
15 control elements, said bitmaps being multiply used 

• -within the control elements, the form being 

generated according to any or all of a user, a. . 
patient, a protocol version within- a clinical trial 
and data previously entered . 
20 " . - 

55. . The system of Claim 54, wherein selected clinical ' 
trial data are displayed at a client, the selection 
being based on any or all of. a user, a patient, a' ^ 
protocol- version within a clinical trial , and data 
25 previously entered . 

56. A -computer system which . discourages inadvertent use 
of a computer application, comprising: • 
. an authentication procedure for each user; and. 



WO 99/63473 



PCT/US99/12406 



-67- 



a picture display, within the application, of 
an authenticated user. 
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